Development of Platform Independent Applications

ABSTRACT

Method, system, and programs for providing packages to applications is disclosed. An application that is executable on a plurality of device platforms is generated. The application is deployed to a client device. A package list received from the client device is analyzed to determine package dependencies for packages on the package list. The packages on the package list and dependent packages are provided based on the package dependencies to the client device. The packages and dependent packages may be installed by the client device to ensure that the application is executable based on characteristics of the client device.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. application Ser. No.13/550,914 filed Jul. 17, 2012, which is a continuation in part of U.S.application Ser. No. 13/437,494 filed Apr. 2 2012, which claims thebenefit of priority to U.S. Provisional Application No. 61/568,056 filedDec. 7, 2011, all of which is incorporated herein by reference in itsentirety.

FIELD

The present disclosure relates to methods, systems and programming fordeveloping platform independent applications. More particularly, thepresent disclosure is directed to methods, systems, and programming fordeveloping applications that may be executed on any device platform.

BACKGROUND OF THE INVENTION

Recent advancements in technology have resulted in increased usage ofdifferent devices and operating systems. Devices such as laptops,smartphones, tablets, and computer systems may operate on a variety ofoperating systems, including Android, Windows, OS X, BlackBerry, andiOS. Users of these devices and operating systems have grown to expectseamless access and increased functionality and interactivity. As aresult, users also expect intercompatibility between different devices.To adhere to the high standards set by users, developers and contentproviders must maintain and develop several versions and permutations oreach application written for each different device and each differentoperating system. For example, the same smartphone application mustoften be written for at least each of the Android, iPhone, and Windowsphone platforms, to say nothing of additional applications that may beneeded for specific smartphones manufactured by Samsung, LG, HTC,T-Mobile, Blackberry, etc. Not only must these different versions ofapplications be developed, but they must also be tested, maintained, andstored. Furthermore, even if the applications are developed to be assimilar as possible across different devices and platforms, users maystill experience different results when accessing the same applicationfrom different smartphones, or from a personal computer, or laptop.

SUMMARY

The embodiments described herein relate to methods, systems, andprogramming for providing packages to applications.

In an embodiment, a method implemented on at least one computing device,each computing device having at least one processor, storage, and acommunication platform connected to a network for providing packages toapplications is disclosed. An application that is executable on aplurality of device platforms is generated. The application is deployedto a client device. A package list received from the client device isanalyzed to determine package dependencies-for packages on the packagelist. The packages on the package list and dependent packages areprovided based on the package dependencies to the client device. Thepackages and dependent packages may be installed by the client device toensure that the application is executable based on characteristics ofthe client device.

In an embodiment, a method implemented on at least one computing device,each computing device having at least one processor, storage, and acommunication platform connected to a network for providing anapplication for execution on a plurality of device platforms isdisclosed. An application that is executable on a plurality of deviceplatforms is generated. Capabilities of the client device are detected.Packages to be applied to the application are determined to ensure thatthe application is executable based on the capabilities of the clientdevice. The application and the packages are deployed to the clientdevice.

In an embodiment, a method implemented on at least one computing device,each computing device having at least one processor, storage, and acommunication platform connected to a network for implementing serverside caching of packages is disclosed. A package list is received from aclient device for an application that is executable on a plurality ofdevice platforms. A determination is made as to which packages from thepackage list are required by the client device. Required packages areadaptively cached for delivery to the client device based on thedetermination.

In an embodiment, a system for providing packages to applications isdisclosed. The system may comprise an application builder for generatingan application that is executable on a plurality of device platforms anddeploying the application to a client device; and a package managementunit for analyzing a package list received from the client device todetermine package dependencies for packages on the package list, andproviding the packages on the package list and dependent packages basedon the package dependencies to the client device, wherein the packagesand dependent packages may be installed by the client device to ensurethat the application is executable based on characteristics of theclient device.

Other concepts relate to software for implementing provision of packagesto applications is disclosed. A software product, in accord with thisconcept, includes at least one machine-readable non-transitory mediumand information carried by the medium. The information carried by themedium may be executable program code data regarding parameters inassociation with a request or operational parameters.

In an embodiment, a machine readable and non-transitory medium havinginformation recorded thereon for providing packages to applications,where when the information is read by the machine, causes the machine toperform the steps comprising: generating an application that isexecutable on a plurality of device platforms; deploying the applicationto a client device; analyzing a package list received from the clientdevice to determine package dependencies for packages on the packagelist; and providing the packages on the package list and dependentpackages based on the package dependencies to the client device, whereinthe packages and dependent packages may be installed by the clientdevice to ensure that the application is executable based oncharacteristics of the client device.

Additional advantages and novel features will be set forth in part inthe description which follows, and in part will become apparent to thoseskilled in the art upon examination of the following and theaccompanying drawings or may be learned by production or operation ofthe disclosed embodiments. The advantages of the present embodiments maybe realized and attained by practice or use of various aspects of themethodologies, instrumentalities and combinations set forth in thedetailed description set forth below.

BRIEF DESCRIPTION OF THE DRAWINGS

The methods, systems, and/or programming described herein are furtherdescribed in terms of exemplary embodiments. These exemplary embodimentsare described in detail with reference to the drawings. Theseembodiments are non-limiting exemplary embodiments, in which likereference numerals represent similar structures throughout the severalviews of the drawings.

FIG. 1 depicts an exemplary prior art system for developing anddeploying applications to different devices.

FIG. 2 depicts a system for developing and deploying a singleapplication that is interoperable with a plurality of device platformsin accordance with an embodiment of the present disclosure.

FIG. 3 depicts an exemplary prior art browser interaction.

FIG. 4 depicts an exemplary results of a browser interaction with aserver browser executing an application in accordance with an embodimentof the present disclosure.

FIG. 5 is a high level depiction of an exemplary system 500 in which adevelopment platform is deployed to provide development and hosting ofapplications that are interoperable between different device platformsand operating systems.

FIG. 6 is a high level depiction of an exemplary system 600 in which adevelopment platform is employed to provide and host applications thatare interoperable between different device platforms and operatingsystems, in accordance with an embodiment of the present disclosure.

FIG. 7 is a high level depiction of an exemplary system 700 in whichdevelopment platform 702 directs distributed hosting of applications, inaccordance with an embodiment of the present disclosure.

FIG. 8 is a high level depiction of an exemplary development and hostingplatform in accordance with an embodiment of the present disclosure.

FIG. 9 depicts an exemplary application MVC architecture in accordancewith an embodiment of the present disclosure.

FIG. 10 depicts an exemplary client-side application execution inaccordance with an embodiment of the present disclosure.

FIG. 11 depicts an exemplary server-side application execution inaccordance with an embodiment of the present disclosure.

FIG. 12 depicts an exemplary view of a client browser running anapplication at a client, and a simulated browser at a server running thesame application, in accordance with an embodiment of the presentdisclosure.

FIG. 13 depicts an exemplary high level system diagram of applicationbuilder 802, in accordance with an embodiment of the present disclosure.

FIG. 14 depicts an exemplary high level system diagram of packagemanagement unit 812, in accordance with an embodiment of the presentdisclosure.

FIG. 15 depicts an exemplary high level system diagram of memorymanagement unit 810, in accordance with an embodiment of the presentdisclosure.

FIG. 16 depicts an exemplary high level system diagram of applicationhoster 816, in accordance with an embodiment of the present disclosure.

FIG. 17 depicts an exemplary high level system diagram of applicationhoster 816, in accordance with an embodiment of the present disclosure.

FIG. 18 depicts an exemplary high level system diagram of applicationbuilder 802, in accordance with an embodiment of the present disclosure.

FIG. 19 depicts a flowchart of an exemplary process in which applicationbuilder 802 is utilized to develop an application, in accordance with anembodiment of the present disclosure.

FIG. 20 depicts a flowchart of an exemplary process in which a user 510of a device can execute an application that is interoperable across aplurality of device platforms, in accordance with an embodiment of thepresent disclosure.

FIG. 21 depicts a flowchart of an exemplary process in which a user 510of a device can execute an application that is interoperable across aplurality of device platforms, in accordance with an embodiment of thepresent disclosure.

FIG. 22 depicts a general computer architecture on which the presentembodiments can be implemented and has a functional block diagramillustration of a computer hardware platform which includes userinterface elements.

DETAILED DESCRIPTION

In the following detailed description, numerous specific details are setforth by way of example in order to provide a thorough understanding ofthe relevant embodiments described herein. However, it should beapparent to those skilled in the art that the present embodiments may bepracticed without such details. In other instances, well known methods,procedures, components and/or circuitry have been described at arelatively high-level, without detail, in order to avoid unnecessarilyobscuring aspects of the embodiments described herein.

The present disclosure relates to methods, systems and programmingdeveloping and hosting platform independent applications. Moreparticularly, the present disclosure is directed to methods, systems,and programming for developing applications that may be executed on anydevice platform. The embodiments described herein provide a platformthat facilitates development and hosting of applications using a cloudinfrastructure. The development and hosting platform may deployapplications to client devices to be run locally at the client device orat a server. The deployed applications may also run off-line locally atthe client device. The platform provides a web application frameworkthat allows an application to execute both at a client or browser sideor at a server side. As a result, application developers do not need towrite different code for a server backend and a browser backend.Additionally, an application may run at the server side even if theclient side encounters problems executing the application, because theapplications all use a single code base. Furthermore, applications mayrun in a hybrid runtime utilizing resources of both a client device orclient browser and a server.

FIG. 1 depicts an exemplary prior art system for developing anddeploying applications to different devices. Server platform 102 isresponsible for deploying different applications 104-1, 104-2, and 104-3to different devices 106-1, 106-2, and 106-3. Each application 104-1,104-2, and 104-3 represents a different version of the “same applicationthat has been programmed to operate and execute specifically on acorresponding device 106-1, 106-2, and 106-3. As shown by FIG. 1, eachdevice requires its own corresponding application to be served to it.For example, application 104-1 corresponds to device 106-1, application104-2 corresponds to device 106-2, and application 104-3 corresponds todevice 106-3. Thus, development of applications can be inefficient, anddue to time and cost constraints for developers, applications tailoredfor certain devices may simply not be developed due to theseconstraints.

FIG. 2 depicts a system for developing and deploying a singleapplication that is interoperable with a plurality of device platformsin accordance with an embodiment of the present disclosure. Developmentand hosting platform 112, described in further detail in the paragraphsbelow, allows developers to develop a single application 114, that maybe deployed to different devices 116-1, 116-2, and 116-3. Application114 is written in a fashion that allows application 114 to beinteroperable between different devices. Thus, developers only need todevelop the application once and serve it across a network to any numberof devices running any type of operating system.

FIG. 3 depicts an exemplary prior art browser interaction In FIG. 3,browser 122 displays an application having four view screens 124-1-4.Each view screen represents a part of the application that is eitherviewable and/or actionable in response to user input. Cursor 126, shownin view screen 124-3 may be clicked or activated by a user. Ifactivation of cursor 126 in view screen 124-3 requests a result from theapplication that browser 122 cannot execute, view screen 124-3 ofbrowser 122 will show an error state, which is shown by browser 128 ofFIG. 3. In certain circumstances, the entire application may crash orcease to operate, simply because a user may have attempted to execute anaction in a view screen of the application that is not supported byeither the operating system or the device in which the browser resides.For example, if clicking in view screen 124-3 represented an attempt tostart a JavaScript application, and the browser, operating system, ordevice does not support JavaScript, then an error will result, such asthat shown in browser 128. Thus, a user is unable to complete their taskor use the application to its full capacity.

FIG. 4 depicts an exemplary result of a browser interaction with asimulated server browser executing an application in accordance with anembodiment of the present disclosure. Browser 122 is the same as the oneshown in FIG. 3, except in this instance, browser 122 is executing anapplication that has been developed to be interoperable betweendifferent device platforms and operating systems, in accordance with theembodiments of the present disclosure. The main difference depicted byFIG. 4 is the result of a user interacting with cursor 126. When a useractivates cursor 126, even if browser 122 is unable to produce aresponse due to incompatibility or a problem with its operating systemor device, browser 122 is able to send the user instruction representingan activation of cursor 126 to server 132. Server 132 may host or run ahosted version of the same application, and carry out the userinstruction, as shown in view screen 134 of simulated browser 136. Theresult of the user instruction may be transmitted back to browser 122and shown within the corresponding view screen of browser 122. Thus,even if browser 122 itself, or its operating system or device, isincapable of producing a response to the user interaction with cursor126, browser 122 may contact server 132 to produce the desired result.Server 132 may transmit a view screen showing the exact results tobrowser 122 so a user of browser 122 can continue using the applicationwithout realizing that the application may have suffered fromcompatibility issues when executed at a client browser.

FIG. 5 is a high level depiction of an exemplary system 500 in which adevelopment platform is deployed to provide development and hosting ofapplications that are interoperable between different device platformsand operating systems, in accordance with an embodiment of the presentdisclosure. Exemplary system 500 includes users 510, network 520, webserver 530, content sources 560, development platform 540, and adatabase 550. Network 520 can be a single network or a combination ofdifferent networks. For example, a network may be a local area network(LAN), a wide area network (WAN), a public network, a private network, aproprietary network, a Public Telephone Switched Network (PTSN), theInternet, a wireless network, a virtual network, or any combinationthereof. A network may also include various network access points, e.g.,wired or wireless access points such as base stations or Internetexchange points 520-1, . . . , 520-2, through which a data source mayconnect to in order to transmit information via the network.

Users 510 may be of different types such as users connected to thenetwork via desktop connections (510-4), users connecting to the networkvia wireless connections such as through a laptop (510-3), a handhelddevice (510-1), or a built-in device in a motor vehicle (510-2). A usermay run applications provided by web server 530, development platform540, or any of content sources 560. Thus, applications may be providedfrom web server 530, development platform 540, or any of content sources560 through network 520. Once a user is running an application on theirdevice, user may send instructions or requests via the application toweb server 530, development platform 540, or any of content sources 560through network 520. The application may also independently communicatewith web server 530, development platform 540, or any of content sources560 through network 520 as needed to ensure that the application canexecute properly.

For example, an application that is interoperable across differentplatforms and operating systems may be provided to any of users 510 byweb server 530, development platform 540, or any of content sources 560through network 520. The application may be developed at developmentplatform 540 but may also be deployed through any of the aforementionedcomponents. The application may also be hosted by development platform540 so that the entire application is executed remotely, with allresults of user interactions with the application provided to the users510.

The content sources 560 include multiple content sources 560-1, 560-2, .. . , 560-3. A content source may correspond to a web page hostcorresponding to an entity, whether an individual, a business, or anorganization such as the USPTO represented by USPTO.gov, a contentprovider such as Yahoo.com, or a content feed source. It is understoodthat any of these content sources may store and host applications thathave been developed using development platform 540 in accordance with anembodiment of the present disclosure. A content source may also include,for example, an application store that provides applications to personalcomputers, laptops, or mobile devices. Web server 530 and developmentplatform 540 may access information from any of content sources 560 andrely on such information to respond to application requests and viceversa. Development platform 540 may also access additional information,via network 520, stored in database 550, which may contain modulesand/or application tools for developing applications.

In exemplary system 500, an application is developed at developmentplatform 540. The application is developed such that the application isinteroperable across different device platforms and operating systems.Additionally, the application is developed such that if the applicationis one requiring a hybrid client device and server runtime, theapplication may execute on its own at a client or user deviceindependent of the device's connection to a server over a network. Theapplication is also developed so that it may adaptively utilize theresources of a server if a server is better suited to execute certainaspects of the application or the entire application. Finally, theapplication is developed so that it may be hosted completely at aserver, which simply provides response to application user input to auser or client device, while the server carries out all instructions andrequests received by the application via user input.

The application need only be developed once and the same application maybe deployed across network 520 to any of users 510. The application maybe deployed to users 510 from any of web server 530, developmentplatform 540, or content sources 560.

In an embodiment, the application is deployed to user 510-1 using amobile device. If, for example, user 510-1 of the mobile device entersan area of limited or no mobile broadband connectivity, the applicationis able to continue executing even though the application cannotestablish a connection with a web server or content source from which itis deployed.

In another embodiment, the application is deployed to user 510-3 using alaptop that is incompatible with the application because the laptop isnot capable of supporting JavaScript. However, development platform 540,from which the application is deployed, may host the application andcarry out any requests of user 510-3 at their laptop. Developmentplatform 540 provides user 510-3 responses to user inputs of theapplication that is viewable and actionable by user 510-3 so that user510-3 does not notice any difference or suffer any consequence fromtheir laptop being incompatible with the application.

FIG. 6 is a high level depiction of an exemplary system 600 in which adevelopment platform is deployed to provide development and hosting ofapplications that are interoperable between different device platformsand operating systems, in accordance with an embodiment of the presentdisclosure. In this embodiment, development platform 540 serves as abackend system of web server 530. All communication to and fromdevelopment platform 540 are sent and received through web server 530.

FIG. 7 is a high level depiction of an exemplary system 700 in whichdevelopment platform 702 directs distributed hosting of applications, inaccordance with an embodiment of the present disclosure. Developmentplatform 702 is a platform that may be used to develop applications thatare interoperable across different device platforms. Applicationsdeveloped by development platform 702 may be deployed to any of servers704, which then host the applications that are eventually distributedfor use by devices 706 over network 708. For example, a developerdevelops an application at development platform 702. The completedapplication is deployed to server 704-1. Server 704-1 is thenresponsible for deploying the application to any of devices 706 overnetwork 708 for usage.

FIG. 8 depicts a high level depiction of an exemplary development andhosting platform in accordance with an embodiment of the presentdisclosure. Development and hosting platform 800 includes an applicationbuilder 802, application development tools 804, modules database 806,applications 808, memory management unit 810, package management unit812, dependencies database 814, and application hoster 816. Applicationbuilder 802, receives developer input, and generates applications 808.Each application that is generated includes at least one module that maybe retrieved from, for example, modules database 806. Applicationdevelopment tools 804 are used to assist in developing the applications.

All applications that are developed are based on a browser based orscripting based application framework. In an embodiment, this browserbased or scripting based application framework is a JavaScriptapplication framework. Thus, in an embodiment, the applications arewritten or coded completely using JavaScript. The JavaScript applicationframework facilitates development of applications that can be executedin both client-side and server-side environments. The JavaScriptapplication framework ensures that developers using application builder802 do not have to write a different set of code for a server backendand a browser frontend. The JavaScript application framework alsoensures that even if a browser attempting to execute the application isnot capable of running JavaScript applications or is not compatible withJavaScript, the application will adapt and execute instead at a serverside. Since all applications may be JavaScript based, a single code basemay be used. A module/widget application framework is also used alongwith the JavaScript application platform by application builder 802 todevelop applications that may be deployed to devices. The applicationframework facilitates the development of transportable code betweenclient devices or browsers at client devices and server. The applicationframework provides a software architecture pattern that isolatesapplication logic for a user from a user interface, thus permittingindependent development, testing, and maintenance of each.

Thus, as discussed above, each application generated by applicationbuilder 802 allows developers to develop one application that isinteroperable between different device platforms and operating systems.The same single application may be deployed to a variety of devices andbe executable on all of them. The applications may be deployed to anydevice that is capable of running or having a browser environmentcapable of executing the applications.

Application development tools 804 facilitates continuous integration oftasks for developers using application builder 802 to developapplications. The development of applications may be monitored, andoutput from the applications reviewed. Application development tools 804may also be used in conjunction with application builder 802 to adddevice specific presentation capabilities to applications.

Memory management unit 810 may be used to add yet another level offunctionality to the applications developed by application builder 802.Before, or after deployment of an application to a device, memorymanagement unit 810 may detect a current or expected memory usage of thedevice. If the application will require more memory than is available atthe device, memory management unit 810 may deploy a memory managementscheme to the device. The memory management scheme ensures that thedevice will always have enough memory to support execution of theapplication. This prevents the application from encountering memoryrelated errors.

Package management unit 812 is responsible for ensuring that deployedapplications are kept updated. Deployed applications may periodically orat user request, submit an update request to package management unit 812to serve updated packages to the applications. The update requestincludes a list of currently installed and additional packages it wantsto acquire. Package management unit 812 checks the package list andobtains package dependencies from dependencies database 814. Packagedependencies ensure that the client device receives not only thepackages it requests, but also additional, and dependent packages thatshould be served to ensure that the application is fully upgraded andable to operate. Package management unit 812 is then able to deploy orserve all updated and required packages to the client deviceautonomously.

Package management unit 812 may also be responsible for ensuring thatthe correct packages are delivered to a client device based on theclient device type. For example, if a client device is a smartphoneoperating on iOS, package management unit 812, ensures that the packagesreceived by the client device are compliant with iOS and are optimizedsuch that the application will execute taking full advantage of thecapabilities of the client device.

In another embodiment, package management unit 812 may facilitateretrieval of partial previews of compatible remote packages notcurrently installed on the client device. Partial previews provide apreview mode for “try before you buy” scenarios which may apply toup-to-date and older version of applications. Compatibly previews may beadaptively served by package management unit 812 based on a currentversion of an application executing on a client device.

For example, if a client device is running an older version of anapplication, the server may need to determine a more appropriate packagecorresponding to an older version of the application. The client devicemay submit a request to package management unit 812 for packages itwishes to preview. Package management unit 812 determines the clientdevice is executing an older version of an application and searches forfiles which have been tagged to represent their association with aparticular version of the application. Once package management unit 812finds the appropriate files, it responds to the client device with thelocation of the files so that the client device may retrieve them.

In another embodiment, package management unit 812 facilitates serverside caching. Server side caching involves package management unit 812making an independent determination of which packages are required at aclient device. This allows package management unit 812 to adaptivelycache certain packages to ensure that required packages are deployed inan efficient manner to prevent any slow down of application execution.Intermediate computations may be cached to aid future package requests.

In another embodiment, package management unit 812 performs adetermination of a minimal set of packages required in order to updatean application at the client device. This minimal set of packagesrepresents only the packages that are not present at the application butare required. This ensures that when a client device sends a list ofpackages to the package management unit 812, package management unit 812will perform an independent determination to determine the minimal setof packages, representing a barebones set of packages necessary toupdate the application at the client device. Thus, this facilitates anefficient usage of resources and ensures that the application will notbe bogged down by receiving too many unnecessary updates at once.

In another embodiment, package management unit 812 may send instructionsto a client device to delete, remove, or clean up packages residing onthe client device related to the application that are no longer needed.Package management unit 812 may also prepare updates to the clientdevice based on asset of transactions defined by package management unit812, with instructions allowing the client device to implement arollback feature in cases where updated packages fail or do not operateas expected on the client device.

Application hoster 816 is a hosting environment for all applicationsdeveloped by application builder 802. More specifically, applicationhoster 816 is a server-side JavaScript hosting environment forapplications, allowing application developers to deploy, un-deploy, andmanage multiple versions of applications. Applications deployed fromapplication hoster 816 are able to be executed on any device platformdue to the platform agnostic nature of the applications. Applicationhoster 816 provides hosting of applications in a network environment.Thus, the servers shown in FIG. 7 are not necessary for hostingdeveloper created applications.

FIG. 9 depicts an exemplary application architecture in accordance withan embodiment of the present disclosure. Application architecture 902represents the application framework used by application builder 802 todevelop applications. Since applications developed using applicationbuilder 802 may be written completely in a browser oriented language ora scripting language. For example, the language may be JavaScript. Itfollows that both client components and server components of anyapplication developed using application builder 802 are written inJavaScript as well. This facilitates the execution of applications onboth a client device or browser at a client device, or at a server. FIG.9 depicts elements of an application architecture 902 and correspondingcomponents.

Application architecture 902 includes client/server executablecomponents 904 and client executable components 906. Client/serverexecutable components 904 include configuration files 908, controllers910, models 912, and views 914. Client executable components 906includes document object models (DOMs) 916 and binders 918.

Configuration files 908 define relationships between code components,assets, routing paths, and defaults. When an application is firstcreated by a developer using application builder 802, configurationfiles are generated. Controllers 910 react to user input and initiateresponses to user input by calling models 912. For example, a particularcontroller associated with a particular model may receive an indicationof a user input and instruct a corresponding model and correspondingview from views 914 to perform actions based on the user input. Models912 manage the behavior and data of an application domain, and respondsto requests for information about its state (from the views), andresponds to instructions to change state (from the controllers). Morespecifically, models 912 notify views 914 about changes in informationso that views 914 can react accordingly. Views 914 renders models 912into forms suitable for interaction, typically in the form of a userinterface element. Multiple views may exist for a single model. Views914 represent what a user of an application sees on a device or browser.

For an application operating at a server side or within a browser at aclient device, client requests for data, or user input, is sent tocontrollers 910, which fetch data from models 912 to pass to views 914.The appropriate output from the views may then be passed back to theclient device.

DOMs 916 assist in rendering views. DOMs 916 are conventions thatrepresent and interact with objects such as views, models, andcontrollers. DOMs 916 and binders 918 are deployed to a client deviceonly since they are only executable at a client device. Binders 918interact with event handlers based on user interface input to anapplication from a user. The event handlers interact with the DOMs 916which in turn invoke functions in the controllers 910 to update contentin views 914. Since DOMs 916 and binders 918 are only client executable,binders receive user input in the form of user interface interactions.The binders 918 interact with the DOMs 916, which communicates with thecontrollers to facilitate client requests.

The user input to controllers 910 at a server side occurs when clientdevice binders 918 cannot interact with controllers 910 via DOMs 916.This causes controllers 910 at a server side to run remote networkrequests that are sent to models 912. The results from models 912 aresent to views 914 to transmit back to the client device for rendering ata client browser.

FIG. 10 depicts an exemplary client-side application execution inaccordance with an embodiment of the present disclosure. Browser 1002represents a client side browser instance running an application inaccordance with the embodiments described herein. Upon activation orclicking of view panel 1004 using cursor 1006, an instruction bound tobinder 1008 invoke an action corresponding with view panel 1004. Theinstruction is sent through module proxy 1010, which serves as a conduitfor sending requests to Core 1012 of the application. The instruction istransmitted through module proxy 1010 to controller 1014, which executesthe instruction at the client side browser based on sending a requestfor information to model 1016. The response to execution of theinstruction at controller 1014 is transmitted through module proxy 1010,back to binder 1008, which interacts with view panel 1004 that will showthe appropriate response.

FIG. 11 depicts an exemplary server-side application execution inaccordance with an embodiment of the present disclosure. Client runtimebox 1102 shows all interactions between browser 1104, binder 1106, andmodule proxy 1108 with respect to a client-side execution of anapplication. Server runtime box 1110 shows a server responding toinstructions sent from module proxy 1108. In this particular example, acertain user input interaction based on cursor 1112 in view panel 1114is unable to be executed at the client side. Thus, an instructionrepresenting the user input interaction is bound to binder 1106. Anaction is invoked by binder 1106, which sends the instruction throughmodule proxy 1108, which serves as a conduit for sending requests todifferent servers that may be hosting or executing the application.Server 1116 receives the instruction, executes the action at theapplication executing at the server side and transmits a response backthrough module proxy 1108 to binder 1106, which interacts with viewpanel 1114 to show the appropriate response to the user inputinteraction or instruction.

FIG. 12 depicts an exemplary view of a client browser running anapplication at a client, and a simulated browser at a server running thesame application, in accordance with an embodiment of the presentdisclosure. Client browser 1202 includes a cursor 1204 for receivinguser input to a view panel 1206. Since client browser 1202 cannotexecute an instruction related to the user input, the instruction issent to server 1208. Server 1208, which is executing the sameapplication at a server side will execute the instruction sent by theclient browser 1202 and provide a response that is viewable within viewpanel 1206 of client browser 1202. The simulated browser 1210 includes aview panel 1212, as well as simulated cursor 1214 which corresponds tothe activities happening at client browser 1202.

FIG. 13 depicts an exemplary high level system diagram of applicationbuilder 802, in accordance with an embodiment of the present disclosure.Application builder 802, which is responsible for developing andgenerating platform independent applications, receives instructions forapplication development, including application parameters, and modulesto include in the application. Application builder 802 also receivesinstructions for adding binders to the application. Binders, asdiscussed above, are set by an application developer. The bindersdictate which event handlers (tied to user interface inputs) may attachwith DOMs that further communicate within the architecture of theapplication. Taking all of the input into account, as well as usingapplication development tools 804, platform agnostic applications areoutput from application builder 802. These applications may then bedeployed to directly to a client device, deployed for serving through adifferent server, such as, for example, one linked or associated with amobile application store, or deployed to application hoster 816 forhosting through a cloud based network.

FIG. 14 depicts an exemplary high level system diagram of packagemanagement unit 812, in accordance with an embodiment of the presentdisclosure. Package management unit 812 is responsible for providingupdates to applications in the form of packages to keep deployedapplications updated. Package management unit 812 receives as input,lists of required packages and currently installed packages. Packagemanagement 812 then uses this received input to cross reference adependencies database to determine what other packages may be requiredin addition to those required for the requested updates. Once the entirepackage list is determined by package management unit 812, the updatesin the form of packages are deployed to the applications. This ensuresthat applications will to the extent possible reflect the latestversion.

In an embodiment, a large set of packages may be a part of a predefinedgrouping which may be referenced with a small amount of information. Forexample, a list of required packages may simply reference a predefinedgrouping of packages as opposed to each package piecemeal.

In another embodiment, package management unit 812 may receive an updaterequest for a past version of an application. In this scenario, packagemanagement unit searches for a corresponding past update package that iscompatible with the update request, and provides the relevant packagesto the application as required.

FIG. 15 depicts an exemplary high level system diagram of memorymanagement unit 810, in accordance with an embodiment of the presentdisclosure. Memory management unit 810 receives as input, memory usageinformation from a device that an application has been deployed ortransmitted to. Prior to execution of the application at the device,memory management unit 810 receives memory usage information andanalyzes the memory usage information. If the memory usage informationshows that the device does not have enough free memory to execute theapplication, memory management unit determines a memory usage scheme forthe device to ensure that the application may be executed. The memoryusage scheme is then transmitted to the device by memory management unit810 for implementation at the device.

FIG. 16 depicts an exemplary high level system diagram of applicationhoster 816, in accordance with an embodiment of the present disclosure.Application hoster 816 receives applications developed by applicationbuilder 802. Application hoster 816 can then host these applications anddeploy them as necessary, while acting as a server for the applications.Application hoster 816 may also receive requests from client devices orother sources, such as developers to host applications. Applicationhoster 816, while hosting applications, can provide results of executinginstructions provided to the hosted applications, to client devices.Also, as will be discussed in further detail below, application hoster816 can analyze analytic information relating to deployment andexecution of applications. This information may be provided todevelopers to assist developers in determining how to further developapplications and tweak existing applications. Since application hoster816 is a hosting platform that hosts applications developed usingapplication builder 802 in a cloud based environment, application hoster816 may also host peripheral services, such as privacy controls andparental controls. These peripheral services may be deployed with any ofthe applications hosted by application hoster 816.

FIG. 17 depicts an exemplary high level system diagram of applicationhoster 816, in accordance with an embodiment of the present disclosure.Application hoster 816 includes serving unit 1702, provisioning unit1706, analytics unit 1708, applications 1710, and peripheral servicesunit 1712. Serving unit 1702 receives requests for applications thathave been deployed by application hoster 816. Any requests forapplications or to perform particular instructions at a particularapplication are processed by serving unit 1702 which routes the requestsappropriately. Provisioning unit 1706 is responsible for deploying thecorrect version of applications to client devices, and for transmittingresponses to client devices based on instructions received. Sincemultiple versions of applications exist and may be stored by applicationhoster 816 (i.e. development application, test application, stagingapplication), application hoster 816 allows developers to deploydifferent applications that may be hosted, for example, on a distributednetwork of servers. The distributed network of servers may comprisemultiple routers fronted by a hardware load balancer to publish changesto applications as they occur. Analytics unit 1708 may extract metricsfrom both serving unit 1702 and provisioning unit 1706. These metricsmay be packaged as a set of information and provided to developers toassist in their application development efforts.

Peripheral services unit 1712 provides peripheral services such asprivacy controls and parental controls to applications deployed byapplication hoster 816. For example, a hosted application may alsoreceive the benefit of a peripheral service allowing parental controlsto be set for the application. If the application were not hosted atapplication hoster 816, this option would not be available.

FIG. 18 depicts an exemplary high level system diagram of applicationbuilder 802, in accordance with an embodiment of the present disclosure.Application builder 802 includes a parameter definition unit 1804,framework unit 1806, and deployment unit 1808. Parameter definition unit1804 allows developers to define application parameters of anapplication allowing the application to be executable on a plurality ofdevice platforms. Parameter definition unit 1804 also allows developersto define configuration parameters of the application and define modulesto be included in the application. Framework unit 1808 allows developersto apply a framework to the application facilitating transportable codebetween a client device and a server to execute the application.Framework unit 1808 may also apply binders to the application to reactto user interface events and apply controllers to the application thatare bound to the binders, the controllers facilitating a response to theuser interface events. The controllers serve data representing responsesto user interface events to a view which corresponds to a displayelement of the application to facilitate display of the responses.Deployment unit 1808 deploys applications that are eventually served toclient devices. The deployment unit may deploy the application to anapplication store, hosting platform, web server, or client device.

FIG. 19 depicts a flowchart of an exemplary process in which applicationbuilder 802 is utilized to develop an application, in accordance with anembodiment of the present disclosure. At 1902, application builder 820defines application parameters of an application allowing theapplication to be executable on a plurality of device parameters.Definition of application parameters is based upon developer input toapplication builder 802. Defining the application parameters includesdefining configuration parameters of the application dictating how theapplication will appear and execute on a plurality of devices. Whichmodules to be included in the application are also defined. At 1904,application builder 802 applies a framework to the applicationfacilitating transportable code between a client device and a server toexecute the application. Application of the framework includes applyingbinders to the application to react to user interface events. Eachbinder may, for example, bind to some type of user interface such asuser input to the application. Controllers are also applied to theapplication. These controllers are bound to the binders and facilitate aresponse to the user interface events. The response may be provided to aclient device executing the application. The controllers may serve datarepresenting responses to user interface events to a view whichcorresponds to a display element of the application facilitating displayof the responses. At 1906, the application is deployed. The deployedapplication may be served or deployed to at least one of an applicationstore, a hosting platform, a web server, or a client device.

FIG. 20 depicts a flowchart of an exemplary process in which a user 510of a device can execute an application that is interoperable across aplurality of device platforms, in accordance with an embodiment of thepresent disclosure. At 2002, an application instruction representing auser interface input is received. At 2004, a binder is invoked based onthe application instruction to call a controller. A binder associatedwith the user interface input is determined, and an action based on thebinder is invoked to call an associated controller to handle producing aresponse to the application instruction. At 2006, a result is determinedwith the controller. At 2008, the result is generated for display at aclient device. Generation of the result for display may take place at atleast one of the client device or a server executing the application.

FIG. 21 depicts a flowchart of an exemplary process in which a user 510of a device can execute an application that is interoperable across aplurality of device platforms, in accordance with an embodiment of thepresent disclosure. At 2102, an application instruction representing auser interface input is received. At 2104, a binder is invoked based onthe application instruction to call a controller. At 2106, adetermination is made whether a response to the application instructioncan be carried out by a controller at a client device. This may entaildetermining if the client device has a requisite capability to executethe application instruction locally. The requisite capability may bebased upon current network connection with a server, or the ability ofthe client device platform or operating system to handle the applicationinstruction. At 1808, a controller associated with the binder at aserver is called to produce the response to the application instruction.This may entail transmitting the application instruction over a networkto the server instructing the server to direct the controller to executethe application instruction and produce a response viewable by theclient device. At 2110, the response to the application instruction fromthe server is received for display at the client device.

To implement the embodiments set forth herein, computer hardwareplatforms may be used as hardware platform(s) for one or more of theelements described herein (e.g., application builder 802, applicationhoster 816, memory management unit 810, and package management unit812). The hardware elements, operating systems and programming languagesof such computer hardware platforms are conventional in nature, and itis presumed that those skilled in the art are adequately familiartherewith to adapt those technologies to implement any of the elementsdescribed herein. A computer with user interface elements may be used toimplement a personal computer (PC) or other type of workstation orterminal device, although a computer may also act as a server ifappropriately programmed. It is believed that those skilled in the artare familiar with the structure, programming, and general operation ofsuch computer equipment, and as a result the drawings areself-explanatory.

FIG. 22 depicts a general computer architecture on which the presentteaching can be implemented and has a functional block diagramillustration of a computer hardware platform which includes userinterface elements. The computer may be a general purpose computer or aspecial purpose computer. This computer 1900 can be used to implementany components of the development and hosting platform described herein.For example, the application builder 802 that develops and generatesapplications, application hoster 816 which deploys and hostsapplications, memory management unit 810 which determines memoryschemes, and package management unit 812 which handles updating ofpackages to applications can all be implemented on a computer such ascomputer 2200, via its hardware, software program, firmware, or acombination thereof. Although only one such computer is shown, forconvenience, the computer functions relating to development and hostingof applications may be implemented in a distributed fashion on a numberof similar platforms, to distribute the processing load.

The computer 2200, for example, includes COM ports 2250 connected to andfrom a network connected thereto to facilitate data communications. Thecomputer 2200 also includes a central processing unit (CPU) 2220, in theform of one or more processors, for executing program instructions. Theexemplary computer platform includes an internal communication bus 2210,program storage and data storage of different forms, e.g., disk 2270,read only memory (ROM) 2230, or random access memory (RAM) 2240, forvarious data files to be processed and/or communicated by the computer,as well as possibly program instructions to be executed by the CPU. Thecomputer 2200 also includes an I/O component 2260, supportinginput/output flows between the computer and other components thereinsuch as user interface elements 2280. The computer 2200 may also receiveprogramming and data via network communications.

Hence, aspects of the methods of developing, deploying, and hostingapplications that are interoperable across a plurality of deviceplatforms, as outlined above, may be embodied in programming. Programaspects of the technology may be thought of as “products” or “articlesof manufacture” typically in the form of executable code and/orassociated data that is carried on or embodied in a type of machinereadable medium. Tangible non-transitory “storage” type media includeany or all of the memory or other storage for the computers, processorsor the like, or associated schedules thereof, such as varioussemiconductor memories, tape drives, disk drives and the like, which mayprovide storage at any time for the software programming.

All or portions of the software may at times be communicated through anetwork such as the Internet or various other telecommunicationnetworks. Such communications, for example, may enable loading of thesoftware from one computer or processor into another, for example, froma server or host computer into the hardware platform(s) of a computingenvironment or other system implementing a computing environment orsimilar functionalities in connection with generating explanations basedon user inquiries. Thus, another type of media that may bear thesoftware elements includes optical, electrical and electromagneticwaves, such as used across physical inter-faces between local devices,through wired and optical landline networks and over various air-links.The physical elements that carry such waves, such as wired or wirelesslinks, optical links or the like, also may be considered as mediabearing the software. As used herein, unless restricted to tangible“storage” media, terms such as computer or machine “readable medium”refer to any medium that participates in providing, instructions to aprocessor for execution.

Hence, a machine readable medium may take many forms, including but notlimited to, a tangible storage medium, a carrier wave medium or physicaltransmission medium. Non-volatile storage media include, for example,optical or magnetic disks, such as any of the storage devices in anycomputer(s) or the like, which may be used to implement the system orany of its components as shown in the drawings. Volatile storage mediaincludes dynamic memory, such as a main memory of such a computerplatform. Tangible transmission media includes coaxial cables, copperwire, and fiber optics, including wires that form a bus within acomputer system. Carrier-wave transmission media can take the form ofelectric or electromagenetic signals, or acoustic or light waves such asthose generated during radio frequency (RF) and infrared (IR) datacommunications. Common forms of computer-readable media thereforeinclude for example: a floppy disk, a flexible disk, hard disk, magnetictake, any other magnetic, medium, a CD-ROM, DVD or DVD-ROM, any otheroptical media, punch card paper tapes, any other physical storage mediumwith patterns of holes, a RAM, a PROM and EPROM, a FLASH-EPROM, anyother memory chip or cartridge, a carrier wave transporting data orinstructions, cables or links transporting such a carrier wave, or anyother medium from which a computer can read programming code and/ordata. Many of these forms of computer readable media may be involved incarrying one or more sequences of one or more instructions to aprocessor for execution.

Those skilled in the art will recognize that the embodiments of thepresent disclosure are amenable to a variety of modifications and/orenhancements. For example, although the implementation of variouscomponents described above may be embodied in a hardware device, it canalso be implemented as a software only solution—e.g., an installation onan existing server. In addition, the dynamic relation/event detector andits components as disclosed herein can be implemented as firmware, afirmware/software combination, a firmware/hardware combination, or ahardware/firmware/software combination.

While the foregoing has described what are considered to be the bestmode and/or other examples, it is understood that various modificationsmay be made therein and that the subject matter disclosed herein may beimplemented in various forms and examples, and that the teachings may beapplied in numerous applications, only some of which have been describedherein. It is intended by the following claims to claim and allapplications, modifications and variations that fall within the truescope of the present teachings.

What is claimed:
 1. A method implemented on at least one computingdevice, each computing device having at least one processor, storage,and a communication platform connected to a network for providingpackages to a client device, the method comprising: deploying anapplication on both a client device and a server device; deploying anupdated version of the application on the sever device; receiving fromthe client device, at the server device, a request to update theapplication; identifying at the server device, one or more packagesassociated with the updated application deployed on the server device;prioritizing at the server device, the one or more packages; selectingat the server device, at least one of the one or more packages based onone or more parameters associated with the client device; and deployingthe at least one of the one or more packages on the client device toupdate the application.
 2. The method of claim 1, further comprising:determining at the server device, a version of the application deployedon the client device from the request; and identifying at the serverdevice, the one or more packages associated with the updated applicationbased on the version of the application deployed on the client device.3. The method of claim 1, further comprising: receiving from the clientdevice, at the server device, a preview request related to one of theone or more packages; obtaining at the server device, a preview resourcedirected to the one of the one or more packages; sending the previewresource to be presented on the client device; and when a selection toinstall the one of the one or more packages is received from the clientdevice at the service device, deploying the one of the one or morepackages on the client device.
 4. The method of claim 1, furthercomprising: receiving at the server device, a current memory usage ofthe client device; and selecting the at least one of the one or morepackages based on the current memory usage of the client device.
 5. Themethod of claim 1, further comprising: receiving at the server device, aprocessing capacity of the client device; and selecting the at least oneof the one or more packages based on the processing capacity of theclient device.
 6. The method of claim 1, further comprising:incorporating an instruction to the at least one of the one or morepackages to be deployed on the client device, wherein the instructionallows the client device to delete the at least one of the one or morepackages from the client device upon detecting that the updatedapplication fails to execute on the client device, and roll back to theapplication before updating.
 7. A system for providing packages to aclient device comprising at least one processor, a storage, acommunication platform connected to a network, wherein the at least oneprocessor is configured by machine-readable instructions to: deploy anapplication on both a client device and a server device; deploy anupdated version of the application on the sever device; receive from theclient device, at the server device, a request to update theapplication; identify at the server device, one or more packagesassociated with the updated application deployed on the server device;prioritize at the server device, the one or more packages; select at theserver device, at least one of the one or more packages based on one ormore parameters associated with the client device; and deploy the atleast one of the one or more packages on the client device to update theapplication.
 8. The system of claim 7, wherein the at least oneprocessor is further configured to determine at the server device, aversion of the application deployed on the client device from therequest; and identify at the server device, the one or more packagesassociated with the updated application based on the version of theapplication deployed on the client device.
 9. The system of claim 7,wherein the at least one processor is further configured to receive fromthe client device, at the server device, a preview request related toone of the one or more packages; obtain at the server device, a previewresource directed to the one of the one or more packages; send thepreview resource to be presented on the client device; and when aselection to install the one of the one or more packages is receivedfrom the client device at the service device, deploy the one of the oneor more packages on the client device.
 10. The system of claim 7,wherein the at least one processor is further configured to receive atthe server device, a current memory usage of the client device; andselect the at least one of the one or more packages based on the currentmemory usage of the client device.
 11. The system of claim 7, whereinthe at least one processor is further configured to receive at theserver device, a processing capacity of the client device; and selectthe at least one of the one or more packages based on the processingcapacity of the client device.
 12. The system of claim 7, wherein the atleast one processor is further configured to incorporate an instructionto the at least one of the one or more packages to be deployed on theclient device, wherein the instruction allows the client device todelete the at least one of the one or more packages from the clientdevice upon detecting that the updated application fails to execute onthe client device, and to roll back to the application before updating.13. A non-transitory machine readable medium having information recordedfor providing packages to a client device, wherein the recordedinformation, when read by a machine, causes the machine to: deploy anapplication on both a client device and a server device; deploy anupdated version of the application on the sever device; receive from theclient device, at the server device, a request to update theapplication; identify at the server device, one or more packagesassociated with the updated application deployed on the server device;prioritize at the server device, the one or more packages; select at theserver device, at least one of the one or more packages based on one ormore parameters associated with the client device; and deploy the atleast one of the one or more packages on the client device to update theapplication.
 14. The non-transitory machine readable medium of claim 13,wherein the recorded information, when read by the machine, furthercauses the machine to: determine at the server device, a version of theapplication deployed on the client device from the request; and identifyat the server device, the one or more packages associated with theupdated application based on the version of the application deployed onthe client device.
 15. The non-transitory machine readable medium ofclaim 13, wherein the recorded information, when read by the machine,further causes the machine to: receive from the client device, at theserver device, a preview request related to one of the one or morepackages; obtain at the server device, a preview resource directed tothe one of the one or more packages; send the preview resource to bepresented on the client device; and when a selection to install the oneof the one or more packages is received from the client device at theservice device, deploy the one of the one or more packages on the clientdevice.
 16. The non-transitory machine readable medium of claim 13,wherein the recorded information, when read by the machine, furthercauses the machine to: receive at the server device, a current memoryusage of the client device; and select the at least one of the one ormore packages based on the current memory usage of the client device.17. The non-transitory machine readable medium of claim 13, wherein therecorded information, when read by the machine, further causes themachine to: receive at the server device, a processing capacity of theclient device; and select the at least one of the one or more packagesbased on the processing capacity of the client device.
 18. Thenon-transitory machine readable medium of claim 13, wherein the recordedinformation, when read by the machine, further causes the machine to:incorporate an instruction to the at least one of the one or morepackages to be deployed on the client device, wherein the instructionallows the client device to delete the at least one of the one or morepackages from the client device upon detecting that the updatedapplication fails to execute on the client device, and to roll back tothe application before updating.